Skip to content

Clean Architecture.md

Latest commit

 

History

History
133 lines (104 loc) · 4.76 KB

Clean Architecture.md

File metadata and controls

133 lines (104 loc) · 4.76 KB
Raw

Clean Architecture

Table of Contents

  1. Clean Architecture
    1. Presentation Layer (User Interface)
    2. Domain Layer (Business Logic)
    3. Data Layer (Data Access)
  2. Data Flow
    1. User → Data
    2. Data ← User
  3. Dependency Direction
  4. References

Clean Architecture

Clean Architecture contains 3 main layers:

  1. Presentation Layer (User Interface).
  2. Domain Layer (Business Logic).
  3. Data Layer (Data Access).

Presentation Layer (User Interface)

Responsibility

Handles interactions between the user and the app.

Implementation

  • Design Paterns used by that layer:
    • MVC, MVP, MVVM, ... - MV*-patterns
  • Examples:
    • View models
    • Views (UIKit or SwiftUI)

Domain Layer (Business Logic)

Responsibility

It contains:

  • Business logic.
  • Business rules:
    • Are described with use cases.
      • Use case defines the behavior of the app in terms of user inputs and matching outputs.
        • Example: what the app should do when user submits a login and a password.
  • Entities.

Implementation

The implementation should contain:

  • Entities
    • Objects that encapsulate critical business rules and data.
    • Business rules are the most important part of this definition.
      • A struct with several fields is not enough to make for an entity.
    • Some business concepts are naturally described by operations rather than data, which leads us to the notion of services.
  • Repository Interfaces / Interfaces
    • They abstract operations that will be performed by data access layer.
  • Use Cases / Interactors / Services
    • A stateless object with operations on data.
      • However, they can mutate global data, leading to side-effects.
    • Input and output: entities and language primitives.
    • Should interact with Repository Interfaces and Entities.
      • Repository Interfaces typically injected in a constructor.
    • Fulfill following operations:
      • Business logic.
      • CRUD (create, read, update, delete) on entities.
      • Networking.
      • Validations.

Data Layer (Data Access)

Responsibility

Contains communication with external data stores such as databases and network.

Implementation

  • Design Paterns used by that layer:
    • Gateway
      • Encapsulates access to external system or resource.
      • It transforms complex API into a convenient one for your app to use.
      • Is client-oriented and not intended for a general-purpose use (Repository is more general-purpose).
    • Repository
      • Encapsulates:
        • Object contained in a data source (e.g. API or database).
        • Operations on those objects.
      • Is more general-purpose compared to Gateway.
      • Can provide authorization capabilities if any required by the underlying data source.
    • Domain Transfer Object
      • An object that contains data without any behavior.
      • Extensively used for communication with network.
        • For this purpose, an intermediate Codable structs are created which reflect the structure of request and response.
  • Implementation:
    • Repositories Implementations + API (Network) + Persistence DB
      • Mapping Codable
      • User Defaults, Core Data
      • Cache, File System
      • REST API

Data Flow

User → Data 

User Interface -> Business Logic -> Data Access

Process can start with a user interaction:

  1. User Interface: A user interacting with the app (UI).
  2. Business Logic: Then the data goes to business logic layer, where it results in CRUD operations on entities.
  3. Data Access: Entities are saved to a backend or a database.

Data ← User 

Data Access -> Business Logic -> Presentation Layer

The reversed process is also the case:

  1. Data Access: The data is fetched from the backend or the database.
  2. Business Logic: The data is transformed by the business rules.
  3. User Interface: The data is finally presented to the user.

Dependency Direction 

User Interface -> Business Logic <- Data Access

Lower-level layers, which are user interface and data access, should depend on the business logic layer.

References